Engenharia de Computação | Gestão de Projetos de Software (2026.2)
| Subitem | Nota / Max | Análise e Justificativa da Pontuação |
|---|---|---|
| 1.1 | 1,0 / 1,5 | Classificou como projeto e listou aspectos de delimitação de escopo, tempo de entrega, equipe e controle de qualidade. Faltou aprofundar na unicidade do produto e caráter temporário formal. |
| 1.2 | 2,0 / 2,0 | Apresentou com clareza duas alternativas no Triângulo de Ferro sem sacrificar qualidade: adicionar membro à equipe (aumentando custo para manter prazo) e renegociar escopo priorizando o MVP funcional. |
| 1.3 | 1,2 / 1,5 | Defendeu abordagem híbrida considerando o planejamento semestral fixo de tarefas acadêmicas combinado com abertura a mudanças contínuas documentadas em sprints. |
| Subitem | Nota / Max | Análise e Justificativa da Pontuação |
|---|---|---|
| 2.1 | 0,6 / 1,5 | Estruturou a EAP restrita apenas ao ambiente de frontend (violando a regra dos 100% ao omitir backend, LLM e relatórios). Confundiu a hierarquia de entregáveis com ordem de execução sequencial de framework. |
| 2.2 | 1,1 / 1,5 | Elaborou duas issues (Tela de chat e Histórico) com descrições e justificou a maior complexidade de conectar banco de dados. Faltou critério de aceitação mensurável e estimativa explícita na 2ª issue. |
| 2.3 | 1,4 / 2,0 | Rejeitou a substituição de sprints por milestones e identificou o Kanban sem sprints como adequado para demandas pontuais e correções finais. |
| Subitem | Nota / Max | Análise e Justificativa da Pontuação |
|---|---|---|
| 3.1 | 1,4 / 1,5 | Definição muito prática e correta de DoD (pronto, testado e validado via QA e pipeline automatizado no GitLab). Sustentou que sem testes a issue não atende à DoD. |
| 3.2 | 1,0 / 1,5 | Classificou as categorias com inversão pontual entre falha interna e externa, mas justificou com muita propriedade que falhas externas geram os maiores prejuízos por atingirem diretamente os clientes. |
| 3.3 | 1,6 / 2,0 | Explicou a progressão temporal de custos na regra 1:10:100 e justificou o valor econômico dos testes preventivos de segurança para evitar vazamento de dados. |
| Subitem | Nota / Max | Análise e Justificativa da Pontuação |
|---|---|---|
| 4.1 | 1,0 / 1,5 | Diferenciou risco de problema, embora tenha subestimado o quadrante na matriz P×I ao marcar probabilidade baixa e impacto médio. |
| 4.2 | 0,0 / 1,5 | Subitem deixado sem resposta (marcado com um grande "X"). |
| 4.3 | 1,2 / 2,0 | Modelou o risco de entrada de prompt injection com exemplo real e propôs mitigação por checagem de palavras-chave registrada em ADR. Faltou abordar o risco de saída (alucinações). |
| Subitem | Nota / Max | Análise e Justificativa da Pontuação |
|---|---|---|
| 5.1 | 1,4 / 1,5 | Ótima comparação entre a rapidez decisória síncrona versus a preservação de foco e rastreabilidade assíncrona, propondo equilíbrio entre dailies rápidas e registro no GitLab. |
| 5.2 | 1,5 / 1,5 | Posicionamento e justificativas excelentes dos 5 stakeholders na matriz Poder × Interesse, com premissas transparentes e planos de comunicação perfeitamente adequados a cada perfil. |
| 5.3 | 0,5 / 2,0 | Defendeu a resposta curta com base em custo e tempo de resposta de API gratuita, mas omitiu a análise formal pelo modelo Thomas-Kilmann e a discussão de abordagens inadequadas. |